In data communications network, in order to improve the utilization of network nodes and network links and reduce the impact of the failure of a single node or a single link on the service traffic, the application of Equal Cost Multiple Paths (ECMP) technology is wider and wider, the ECMP technology may distribute the service traffics with the same source and the same destination into different flows, so that different flows can be forwarded along different transmission paths of equal cost.
In order to realize ECMP, generally, forwarding table entries comprising a plurality of outbound interfaces are firstly calculated using routing protocols such as intermediate system to intermediate system (IS-IS) or open shortest path first (OSPF) on a network node. After having received a packet which is to be forwarded and matches the forwarding table entry, the network node performs hash calculation on some preset fields (such as IP quintuple comprising a source IP address, a source port, a destination IP address, a destination port and a transport layer protocol number) of the packet, then a modular (mod) operation is performed on the number of outbound interfaces through a hash value, so as to obtain an outbound interface index, so that one of the plurality of outbound interfaces included in the forwarding table entry can be selected according to the index, and then the packet is forwarded from the selected outbound interface. Since values of the above-mentioned pre-set fields included in the packet matching the above-mentioned forwarding table entry may be different, and the network node may calculate different hash values according to different values of the fields; therefore, service traffics matching the same forwarding table entry are distributed to different flows on a single network node, and different outbound interfaces are selected for different flows. All the nodes in the network perform the above-mentioned operations of distributing service traffics to different flows and selecting different outbound interfaces for different flows, so that the technological purpose of ECMP can be achieved.
An overlay network represented by a Multi-Protocol Label Switching (MPLS) network and a Provider Backbone Bridging (PBB) network is a very common data communication network of the current application. The so-called overlay network is configured to divide a network into an overlay network edge layer and an overlay network core layer, the overlay network edge layer is responsible for performing encapsulation on an original packet entering the overlay network, the destination address of the encapsulated packet points to an remote edge node of the overlay network, the overlay network edge layer is also responsible for performing decapsulation on the encapsulated packet which is forwarded out of the overlay network, and the overlay network core layer is responsible for forwarding the encapsulated packet according to the destination address of the encapsulated packet. The edge nodes of the overlay network complete the function of overlay network edge layer, and the edge nodes and the intermediate nodes of the overlay network together complete the function of the overlay network core layer. If it is desired to realize ECMP in the overlay network, there is a method that a core layer (comprising edge nodes and intermediate nodes) of the overlay network performs a hash calculation on some preset fields (such as IP quintuple) comprising an original packet in the encapsulated packet, and selects an outbound interface according to hash calculation; however, the method requires that the network node extracts some preset fields comprising an original packet in the encapsulated packet, since the fields of the original packet are located at a relatively deep position in the encapsulated packet, extracting these fields is a relatively heavy burden for the network node, and the realization of the existing hardware devices are relatively complex and expensive. In order to solve the defects of the above-mentioned method, the Internet Engineering Task Force (IETF) and the Institute of Electrical and Electronics Engineers (IEEE) respectively propose similar solutions for the MPLS network and the PBB network, the fundamental principle is that firstly a flow identifier is encapsulated to the original packet entering the overlay network on the edge layer of the overlay network, and then a standardized MPLS encapsulation or PBB encapsulation is performed, the value of the flow identifier comes from a result (i.e. hash value) of hash calculation on some preset fields (such as IP quintuple) of the original packet, when the core layer of the overlay network performs hash calculation on the encapsulated packet to select an outbound interface, there is no need to extract some fields of the original packet located at a relatively deep position in the encapsulated packet, and only a flow identifier which represents the flow information of the original packet and is located at a relatively shallow position in the encapsulated packet needs to be extracted, so that the burden of the network node is greatly alleviated, and the complexity and high costs of the hardware implementation are shielded. In the IETF standard RFC 6391, in order to realize ECMP based on a Pseudo Wire (PW) in the MPLS network, a Flow Label (FL) used as the flow identifier is specified, the position of the flow label in the encapsulated packet is as shown in FIG. 1; in the IETF standard RFC 6790, in order to realize ECMP based on a Label Switched Path (LSP) in the MPLS network, an Entropy Label (EL) used as the flow identifier is specified, the position of the entropy label in the encapsulated packet is as shown in FIG. 2; and in the IEEE standard 802.1Qbp, in order to realize ECMP in the PBB network, a Flow Filtering Tag (F-TAG) used as the flow identifier is specified, the position of the flow filtering tag in the encapsulated packet is as shown in FIG. 3.
With the proposing of the concept of Software Defined Network (SDN) and the development of the application thereof, the OpenFlow technology, as the SDN core technology, is in a stage of rapid development, and at present, the OpenFlow network built using the OpenFlow technology has been increasingly used in the actual production life. The OpenFlow network uses an architecture where a control plane and a forwarding plane (also called as data plane) are separated. FIG. 4 is an architecture schematic diagram of an OpenFlow network component according to the related art; as shown in FIG. 4, the management plane of the OpenFlow network is realized by OpenFlow configuration point, which is a device running network management software, and the specific device form thereof may be a personal computer or a server and the like. The control plane of the OpenFlow network is realized by an OpenFlow controller, which is a device having a powerful computing capability, and the specific device form thereof may be a personal computer, a server or a server cluster the like, and a network application (APP) may invoke the OpenFlow controller by an application programming interface (API), so as to realize the control of the OpenFlow network. The forwarding plane of the OpenFlow network is realized by an OpenFlow switch, which is a device having a powerful switching capability, and the specific device form thereof is a network device configured with a plurality of network ports and performing packet processing and forwarding based on a flow table. An OpenFlow management and configuration (OF-Config) protocol is operated at an interface between the OpenFlow configuration point and the OpenFlow switch, and an OpenFlow switch (OF-Switch) protocol is operated at an interface between the OpenFlow controller and the OpenFlow switch. The Open Networking Foundation (ONF) is responsible for making and modifying the above-mentioned two protocols.
The ONF formally issues the 1.1.1 version of the OF-Config protocol on March 2013 and specifies the flow of the OF-Config protocol. The ONF formally issues the 1.4.0 version of the OpenFlow switch specification on October 2013, which specifies the flow of the OF-Switch protocol and the packet processing flow inside the OpenFlow switch, wherein the method on how to realize adding the outer label and assigning a value to the outer label on the OpenFlow switch is included. FIG. 5 is a schematic flow chart of packet processing for the OpenFlow switch to realize adding an outer label and assigning a value to the outer label according to the related art. As shown in FIG. 5, flow table matching is firstly performed on a packet entering the OpenFlow switch from an ingress port, wherein the flow table is sent down by the OpenFlow controller to OpenFlow switch through the OF-Switch protocol in advance. FIG. 6 is a format diagram of an OpenFlow flow table according to the related art, as shown in FIG. 6, the flow table may comprise a plurality of flow table entries, the match fields in each flow table entry may be any field (such as an MAC address field, an IP address field and an MPLS label field) in the packet header. After the flow table matching is completed, instructions in the corresponding flow table entry will be performed on the packet matching flow table successfully, wherein the instructions may comprise one or more actions, that is, a plurality of actions may be performed sequentially on packets matching flow table successfully. Two continuous actions of “pushing a label (Push-Tag)” and “assigning the label (Set-Field)” may be respectively for adding an outer label and assigning a value to the outer label, wherein the action of Push-Tag for adding an outer label not only can support adding an outer MPLS label, but also can support adding an outer PBB label or adding an outer VLAN label, since the flow label specified in the IETF standard RFC 6391 and the entropy label specified in the RFC 6790 have the same form definition with the MPLS label, and the flow filtering tag specified in the IEEE standard 802.1Qbp have similar form definitions with the VLAN tag, it can be considered that the action of Push-Tag in the related art may support adding various flow identifiers, and the action of Set-Field may support the assignment of various added outer label (such as an MPLS label, a PBB label or a VLAN tag); however, only an explicit numerical value (such as 100) may be assigned, since the flow identifier is also a kind of outer label, it can be considered that the action of Set-Field in the related art can support the explicit assignment of the flow identifier.
In summary, according to the current OpenFlow switch specification, the OpenFlow switch (i.e., an OpenFlow network node) can only assign an explicit numerical value to a new added outer label, and it cannot be achieved that a hash calculation result (i.e., hash value) of some fields comprising an original packet before encapsulation is used as the assignment of a new added flow identifier, which is required by the encapsulation of the flow identifier.
For the problem in the related art that the OpenFlow switch cannot realize the encapsulation of the flow identifier, no effective solution has been provided at present.